ci: add release-please for versioned contract releases by max-parke-scale · Pull Request #321 · scaleapi/scale-agentex

max-parke-scale · 2026-06-17T16:58:15Z

What

Adds release-please so merges to main cut versioned releases — a vX.Y.Z git tag + GitHub release + CHANGELOG — from the conventional commits already enforced here.

release-please-config.json — release-type: simple, vX.Y.Z tags (no component), pre-1.0 bump rules, changelog sections.
.release-please-manifest.json — seeds the version at 0.1.0 (matches pyproject.toml).
.github/workflows/release-please.yml — runs on main + workflow_dispatch.

Why

scale-agentex has no version axis of its own: it floats at head, and the only version concept comes from SGP's platform release. So there's no way to name an "oldest supported server contract" that downstream consumers can target.

This gives scale-agentex its own contract version axis — each release tag is an immutable snapshot of agentex/openapi.yaml. The SDK's cross-version compatibility suite (scale-agentex-python#407) can then pin min-supported to a real release tag instead of the placeholder commit SHA it uses today.

These are contract checkpoints, not a deploy gate — the server still floats at head for deploys. The release version is a separate axis from SGP's platform version; don't read them as the same.

Bootstrap

Seeded at 0.1.0 with bootstrap-sha at the current main HEAD, so the changelog starts fresh (no history backfill). After merge, the first feat/fix PR (or a manual workflow_dispatch) opens the first release PR; merging it cuts the first tag. The release PR title is chore: release …, which passes the PR-title check.

Next (the SGP hookup — separate)

Tag the built image with the release version in build-agentex.yml (today it's :sha/:latest) so deploys get a version handle.
Have SGP pin agentex by version, so "oldest supported" becomes derivable from the oldest live SGP release rather than a hand-maintained floor.

Note: tags/releases created with the default GITHUB_TOKEN don't trigger other workflows, so the image-on-release build (1) will need a PAT or repository_dispatch.

Decision to confirm

Seed version 0.1.0 (matches pyproject.toml). Bump to 1.0.0 instead if you want the first tag to signal contract stability.

🧑‍💻🤖 — posted via Claude Code

Greptile Summary

Adds Release Please automation for versioned Agentex contract releases on main and manual dispatch.

Seeds the release manifest at 0.1.0.

Introduces a shared Agentex version source and wires FastAPI/OpenAPI versioning to it.

Configures coordinated version bumps for Python package metadata, backend metadata, OpenAPI info.version, and the shared version file.

Confidence Score: 5/5

The changes are limited to release automation and version metadata wiring, with no blocking code issues identified.

The workflow, manifest, configuration, and shared version source align with the described release process and appear safe to merge.

T-Rex Logs

What T-Rex did

Compared the before and after release-please configuration states; the before state had all three files absent and overall validation failing, while the after state has the files present and most checks passing, with contract checks failing for specific items.
Compared the before and after OpenAPI version wiring states; the before state showed base commit, no agentex/src/_version.py, and no explicit version in FastAPI, with /openapi.json returning 200 OK and info.version=0.1.0, while the after state shows head commit, a defined __version__ in _version.py, FastAPI(version=__version__), and /openapi.json returning 200 OK with info.version=0.1.0; no contract-mismatch was filed because the head imports and the app responds as expected, and OpenAPI exposes 0.1.0 from the new wiring.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

General comment

Release-please package metadata and pre-major patch bump setting contradict the claimed contract
- Bug
  - The head release-please configuration is present and parseable, but it does not semantically match the requested contract for versioned contract checkpoint releases. In release-please-config.json, the root package is configured with release-type: "python" and package-name: "agentex" instead of the claimed release-type: "simple" and package-name: "contract-checkpoints". The same config also sets bump-patch-for-minor-pre-major to false, while the validation objective expected the pre-1.0 bump boolean to be enabled. The executed after artifact reports these exact failed checks while the before artifact shows the config was absent on base.
- Cause
  - Changed lines in release-please-config.json implement package metadata and bump behavior that target the Python package (agentex) rather than the claimed simple contract-checkpoint release package, and disable patch bumps for minor pre-major changes.
- Fix
  - Update release-please-config.json so the root package uses "release-type": "simple", "package-name": "contract-checkpoints", and set "bump-patch-for-minor-pre-major": true if the intended contract is the one described in the PR/validation objective. If the actual intended release is the Python package release, update the PR description and release contract accordingly.
_{Ran code and verified through T-Rex}

_{Reviews (4): Last reviewed commit: "ci: add release-please for versioned, se..." | Re-trigger Greptile}

scale-agentex has no version axis of its own — it floats at head, and the only version concept comes from SGP's platform release. That leaves no way to name an "oldest supported server contract" for downstream consumers. Add release-please (release-type: python; conventional-commit PR titles already enforced) so merges to main cut versioned releases: a vX.Y.Z git tag + GitHub release + CHANGELOG. Make the contract self-describe its version so the tag and spec never drift: - src/_version.py is the single source; the FastAPI app reads it (version=__version__), so generate_openapi_spec.py emits it as info.version. - release-please bumps src/_version.py, agentex/openapi.yaml (info.version), agentex/pyproject.toml, and the root pyproject together with the tag. Each tag is thus an immutable, self-describing snapshot of agentex/openapi.yaml the SDK's cross-version compat suite can pin as min-supported (scaleapi/scale-agentex-python#407), replacing the placeholder commit SHA today. Contract checkpoints, not a deploy gate: the server still floats at head for deploys. Seeded at 0.1.0 with bootstrap-sha at current main HEAD so the changelog starts fresh; the first feat/fix merge (or workflow_dispatch) cuts the first release. Verified gen-openapi emits info.version from _version.py with no spec drift. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The googleapis/release-please-action isn't on the org Actions allow-list, so the release-please workflow added in #321 failed at startup (no release PR cut). Run the release-please CLI under actions/setup-node (allow-listed) instead — same manifest-mode behavior (release-pr + github-release), no third-party action. Verified the CLI commands/flags against release-please@16. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

## What Rewrites the release-please workflow (added in #321) to run the release-please **CLI** under `actions/setup-node`, instead of `googleapis/release-please-action`. ## Why After #321 merged, the workflow **failed at startup** on every push to `main` (`startup_failure`, no logs, no release PR cut). The merged YAML is valid and the action SHA resolves — the cause is the org Actions **allow-list**: `googleapis/release-please-action` isn't on it. (Every other workflow here uses only `actions/`, `astral-sh/`, `docker/`, `stainless-api/`, `codecov/`, `dorny/`; the Actions-policy API is admin-only/403 for me, so I couldn't read it directly, but the signature is unambiguous.) ## Fix Run `npx release-please@16 release-pr` + `github-release` (manifest mode — same as the action did internally) under `actions/setup-node@v4`, which is allow-listed (`actions/*` is used throughout the repo). No third-party action → allow-list-proof. Verified the CLI commands (`release-pr`/`github-release`; `manifest-pr`/`manifest-release` are deprecated aliases) and flags (`--token`, `--repo-url`, `--config-file`, `--manifest-file`) against `release-please@16`. ## After merge Runs on `main`; once a `feat`/`fix` lands (or via `workflow_dispatch`) it opens the first release PR → merging that cuts the first `vX.Y.Z` tag. Config + manifest are unchanged from #321. 🧑‍💻🤖 — posted via [Claude Code](https://claude.com/claude-code)   <h3>Greptile Summary</h3> - Replaces the blocked `googleapis/release-please-action` workflow step with direct `release-please@16` CLI commands. - Sets up Node 20 through `actions/setup-node@v4` before running release PR and GitHub release commands. - Keeps the existing release-please config and manifest files while adding `issues: write` for label management. <details><summary><h3>Confidence Score: 5/5</h3></summary> The workflow change is narrowly scoped to replacing a blocked GitHub Action with equivalent CLI invocations. Only one CI workflow file changed, the release-please config and manifest remain unchanged, and no code issues were identified. </details> <details><summary><h3><a href="https://www.greptile.com/trex"><img alt="T-Rex" src="https://greptile-static-assets.s3.amazonaws.com/trex/trex_green.svg" height="20" align="absmiddle"></a> T-Rex Logs</h3></summary> **What T-Rex did** - The T-Rex run performed a pre-artifact check by inspecting the base release-please CLI workflow using git show and grep probes. - The T-Rex run performed a post-artifact validation that included a second git show, YAML parse success, workflow contract probes, referenced file checks, and the release-please@16 CLI version/help output. - The T-Rex run confirmed the overall step completed with FINAL\_EXIT\_CODE: 0. <a href="https://app.greptile.com/trex/runs/11434739/artifacts"><picture><source media="(prefers-color-scheme: dark)" srcset="https://greptile-static-assets.s3.amazonaws.com/badges/ViewAllArtifactsDark.svg?v=1"><source media="(prefers-color-scheme: light)" srcset="https://greptile-static-assets.s3.amazonaws.com/badges/ViewAllArtifacts.svg?v=1"><img alt="View all artifacts" src="https://greptile-static-assets.s3.amazonaws.com/badges/ViewAllArtifacts.svg?v=1" height="32"></picture></a> <sub><a href="https://www.greptile.com/trex"><img alt="T-Rex" src="https://greptile-static-assets.s3.amazonaws.com/trex/trex_green.svg" height="14" align="absmiddle"></a> Ran code and verified through T-Rex</sub> </details>  <details open><summary><h3>Comments Outside Diff (1)</h3></summary> 1. `.github/workflows/release-please.yml`, line 12-14 ([link](https://github.com/scaleapi/scale-agentex/blob/70d312412b8b374d141bc0aece5723043bd20e11/.github/workflows/release-please.yml#L12-L14)) <a href="#"><img alt="P1" src="https://greptile-static-assets.s3.amazonaws.com/badges/p1.svg?v=9" align="top"></a> **Grant label permissions** The CLI still applies and removes release-please labels on release PRs, and those calls go through GitHub's Issues API. This workflow only grants `contents: write` and `pull-requests: write`, so the job can fail with a permissions error when it tries to add or remove labels like `autorelease: pending`. Add `issues: write` here so the CLI has the same label permissions the release flow needs. <details><summary>Prompt To Fix With AI</summary> `````markdown This is a comment left during a code review. Path: .github/workflows/release-please.yml Line: 12-14 Comment: **Grant label permissions** The CLI still applies and removes release-please labels on release PRs, and those calls go through GitHub's Issues API. This workflow only grants `contents: write` and `pull-requests: write`, so the job can fail with a permissions error when it tries to add or remove labels like `autorelease: pending`. Add `issues: write` here so the CLI has the same label permissions the release flow needs. How can I resolve this? If you propose a fix, please make it concise. ````` </details> <a href="https://app.greptile.com/api/ide/cursor?prompt=This%20is%20a%20comment%20left%20during%20a%20code%20review.%0APath%3A%20.github%2Fworkflows%2Frelease-please.yml%0ALine%3A%2012-14%0A%0AComment%3A%0A**Grant%20label%20permissions**%0A%0AThe%20CLI%20still%20applies%20and%20removes%20release-please%20labels%20on%20release%20PRs%2C%20and%20those%20calls%20go%20through%20GitHub's%20Issues%20API.%20This%20workflow%20only%20grants%20%60contents%3A%20write%60%20and%20%60pull-requests%3A%20write%60%2C%20so%20the%20job%20can%20fail%20with%20a%20permissions%20error%20when%20it%20tries%20to%20add%20or%20remove%20labels%20like%20%60autorelease%3A%20pending%60.%20Add%20%60issues%3A%20write%60%20here%20so%20the%20CLI%20has%20the%20same%20label%20permissions%20the%20release%20flow%20needs.%0A%0AHow%20can%20I%20resolve%20this%3F%20If%20you%20propose%20a%20fix%2C%20please%20make%20it%20concise.&pr=324&platform=github"><picture><source media="(prefers-color-scheme: dark)" srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixInCursorDark.svg?v=3"><source media="(prefers-color-scheme: light)" srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixInCursor.svg?v=3"><img alt="Fix in Cursor" src="https://greptile-static-assets.s3.amazonaws.com/badges/FixInCursor.svg?v=3" height="20"></picture></a> <a href="https://app.greptile.com/ide/claude-code?prompt=This%20is%20a%20comment%20left%20during%20a%20code%20review.%0APath%3A%20.github%2Fworkflows%2Frelease-please.yml%0ALine%3A%2012-14%0A%0AComment%3A%0A**Grant%20label%20permissions**%0A%0AThe%20CLI%20still%20applies%20and%20removes%20release-please%20labels%20on%20release%20PRs%2C%20and%20those%20calls%20go%20through%20GitHub's%20Issues%20API.%20This%20workflow%20only%20grants%20%60contents%3A%20write%60%20and%20%60pull-requests%3A%20write%60%2C%20so%20the%20job%20can%20fail%20with%20a%20permissions%20error%20when%20it%20tries%20to%20add%20or%20remove%20labels%20like%20%60autorelease%3A%20pending%60.%20Add%20%60issues%3A%20write%60%20here%20so%20the%20CLI%20has%20the%20same%20label%20permissions%20the%20release%20flow%20needs.%0A%0AHow%20can%20I%20resolve%20this%3F%20If%20you%20propose%20a%20fix%2C%20please%20make%20it%20concise.&repo=scaleapi%2Fscale-agentex&pr=324&platform=github"><picture><source media="(prefers-color-scheme: dark)" srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixInClaudeDark.svg?v=3"><source media="(prefers-color-scheme: light)" srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixInClaude.svg?v=3"><img alt="Fix in Claude Code" src="https://greptile-static-assets.s3.amazonaws.com/badges/FixInClaude.svg?v=3" height="20"></picture></a> <a href="https://app.greptile.com/api/ide/codex?prompt=IMPORTANT%3A%20Work%20in%20the%20repository%20%22scaleapi%2Fscale-agentex%22%20on%20the%20existing%20branch%20%22maxparke%2Ffix-release-please-npx%22.%20Checkout%20that%20branch%20%E2%80%94%20do%20NOT%20create%20a%20new%20branch%20or%20open%20a%20new%20PR.%20Push%20your%20changes%20to%20%22maxparke%2Ffix-release-please-npx%22.%0A%0AThis%20is%20a%20comment%20left%20during%20a%20code%20review.%0APath%3A%20.github%2Fworkflows%2Frelease-please.yml%0ALine%3A%2012-14%0A%0AComment%3A%0A**Grant%20label%20permissions**%0A%0AThe%20CLI%20still%20applies%20and%20removes%20release-please%20labels%20on%20release%20PRs%2C%20and%20those%20calls%20go%20through%20GitHub's%20Issues%20API.%20This%20workflow%20only%20grants%20%60contents%3A%20write%60%20and%20%60pull-requests%3A%20write%60%2C%20so%20the%20job%20can%20fail%20with%20a%20permissions%20error%20when%20it%20tries%20to%20add%20or%20remove%20labels%20like%20%60autorelease%3A%20pending%60.%20Add%20%60issues%3A%20write%60%20here%20so%20the%20CLI%20has%20the%20same%20label%20permissions%20the%20release%20flow%20needs.%0A%0AHow%20can%20I%20resolve%20this%3F%20If%20you%20propose%20a%20fix%2C%20please%20make%20it%20concise.&repo=scaleapi%2Fscale-agentex&pr=324&platform=github"><picture><source media="(prefers-color-scheme: dark)" srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixInCodexDark.svg?v=3"><source media="(prefers-color-scheme: light)" srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixInCodex.svg?v=3"><img alt="Fix in Codex" src="https://greptile-static-assets.s3.amazonaws.com/badges/FixInCodex.svg?v=3" height="20"></picture></a> </details>  <sub>Reviews (2): Last reviewed commit: ["ci: run release-please via CLI instead o..."](b21deb7) | [Re-trigger Greptile](https://app.greptile.com/api/retrigger?id=38215319)</sub>  Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

max-parke-scale requested a review from a team as a code owner June 17, 2026 16:58

greptile-apps Bot reviewed Jun 17, 2026

View reviewed changes

Comment thread release-please-config.json Outdated

Comment thread release-please-config.json

max-parke-scale force-pushed the maxparke/add-release-please branch 2 times, most recently from 7206698 to 69d49bb Compare June 17, 2026 17:39

NiteshDhanpal approved these changes Jun 17, 2026

View reviewed changes

max-parke-scale force-pushed the maxparke/add-release-please branch from 69d49bb to 4fd3813 Compare June 17, 2026 18:17

This was referenced Jun 17, 2026

feat(adk): warn when the agentex server reports an unsupported version scaleapi/scale-agentex-python#410

Closed

feat(api): advertise contract version via X-Agentex-Version response header #322

Closed

max-parke-scale merged commit a51ed7a into main Jun 17, 2026
31 checks passed

max-parke-scale deleted the maxparke/add-release-please branch June 17, 2026 18:58

max-parke-scale mentioned this pull request Jun 17, 2026

ci: run release-please via CLI instead of the googleapis action #324

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ci: add release-please for versioned contract releases#321

ci: add release-please for versioned contract releases#321
max-parke-scale merged 1 commit into
mainfrom
maxparke/add-release-please

max-parke-scale commented Jun 17, 2026 •

edited by greptile-apps Bot

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

max-parke-scale commented Jun 17, 2026 • edited by greptile-apps Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Why

Bootstrap

Next (the SGP hookup — separate)

Decision to confirm

Greptile Summary

Confidence Score: 5/5

T-Rex Logs

Comments Outside Diff (1)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

max-parke-scale commented Jun 17, 2026 •

edited by greptile-apps Bot

Loading